-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model Dapr sidecar as an Aspire resource #1604
Model Dapr sidecar as an Aspire resource #1604
Conversation
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
We'll end up having 3 resources in the UI once we do this #436 |
Signed-off-by: Phillip Hoff <[email protected]>
I'm ok with that, though I'm curious as to what the UX for that will be like. It'd be neat to be able to arrange the resources in some sort of hierarchical way. |
Any idea when the preview3 with this feature will be available? |
February is the next release. You can use ci builds to help verify this feature though. |
thanks ^_^ |
Currently, Dapr sidecars are modeled as annotations on a parent resource, which indicates the need for a Dapr sidecar started for that resource. The Dapr lifecycle hook will then generate appropriate Dapr CLI executable resources to start the sidecars. When publishing, that hook will write Dapr sidecar resources to the manifest.
This model has a disadvantage in that, because the sidecars are not true resources, users cannot modify them like other resources (e.g. set environment variables). This was done originally due to the tight 1:1 mapping between Dapr sidecar and parent resource. For example, it would be semantically invalid to create a Dapr sidecar resource and then reference it from several resources.
This PR updates the model such that the Dapr sidecar is a true resource, but one exposed only through the existing
AddDaprSidecar()
API to avoid semantic errors; users cannot create an arbitrary Dapr sidecar resource, only configure the one associated with a given resource. The API allows the existing sidecar options (if any) to be specified, as well as use the existing resource annotation helpers, such asWithEnvironment()
.The API looks like:
Resolves #1553
Microsoft Reviewers: Open in CodeFlow